…AN-0008)

Implements ADR-0008: extracts CombatantBehavior/CombatResolver/CombatManager/
AttackCommand/FleeCommand out of the Classic sample into a new
SharpMud.Ruleset.Rpg package, decoupling its stats-behavior/respawn touches
behind a new ICombatOutcomeHandler seam, adding a DI-registered IDiceRoller
over IRandomSource, and fixing a pre-existing bug where a respawned
character's CombatantBehavior.CurrentHitPoints was never reset. Adds a new
minimal SharpMud.Ruleset.Basic package built on Ruleset.Rpg for a true
"dotnet add package, few lines, run a basic game" quick-start. Classic is
rebuilt on Ruleset.Rpg instead of owning combat scaffolding directly.

Also: dependabot now ignores the conditional/range-pinned packages it can't
reliably update, Directory.Packages.props centralizes the lockstep
net10.0/net11.0 Microsoft.* version ranges into one property per TFM, and
the docsite gains Rulesets/Customizing pages.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Fixes two real death-penalty bugs found by review: CombatManager reset
CombatantBehavior.CurrentHitPoints to full before the outcome handler ran,
but neither ClassicCombatOutcomeHandler nor BasicCombatOutcomeHandler
actually halved it back down, so the documented "respawn at half HP"
penalty was silently a no-op for both rulesets. Also fixes a player-facing
message-order regression (defeat message now precedes the outcome handler's
own messages again, matching pre-extraction behavior), adds a guard so
AttackCommand fails cleanly instead of crashing at tick time when the actor
has no CombatantBehavior, adds fail-fast validation to BasicRulesetOptions,
and adds XML doc comments across the new public surface in both packages.

Also: docs/getting-started.md's package install commands now include
--prerelease (alpha packages, none published as stable yet), and several
docs/*.md sections left stale by the extraction (combat.md's code sketch,
engine-vs-ruleset.md's ruleset-behaviors listing, a small ADR-0008 typo) are
brought current. ADR-0008's Open Items are updated to record the decisions
actually made during implementation (meta-package exclusion, the
ICombatOutcomeHandler mechanism, and the forwarding-callback command
composition), rather than left as still-open questions.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Fixes a real, pre-existing bug FleeCommand carried over from before this
PR's extraction: it moved the actor directly instead of publishing the same
UseExitEvent request MoveCommand does, so a locked exit blocked a normal
move but not a flee through the exact same exit. FleeCommand now checks the
lock (or any future exit veto) before ending the encounter and moving.

Also: adds the test coverage the first review-feedback fix was missing
(CombatantBehavior.CurrentHitPoints assertions in Classic's outcome-handler
test, plus a new BasicCombatOutcomeHandlerTests covering the same death
penalty for Basic - neither existed before, so the HP-halving fix itself
had no regression coverage where it actually mattered); narrows
CombatantBehaviorConfiguration/BasicStatsBehaviorConfiguration to internal
(never referenced by name outside their own assembly, discovered only via
EF's ApplyConfigurationsFromAssembly reflection scan - confirmed still
works internal via the persistence round-trip tests); and brings
docs/combat.md, docs/architecture.md, docs/plans/0008-ruleset-scaffolding-tier.md,
and docsite/docs/rulesets.md up to date with the HP-halving fix and the
FleeCommand fix from this round.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Two more real bugs, both in shared combat scaffolding:

- CombatManager tracked encounters keyed by attacker only, so a second
  player could start an independent encounter against a defender someone
  else was already fighting - both encounters would then resolve, remove,
  and award victory independently for the same kill (duplicate XP). Added
  ICombatManager.IsDefenderEngaged, checked by AttackCommand before
  starting a new encounter.

- FleeCommand ignored Remove's return value and unconditionally added the
  actor to the destination room afterward. Remove can itself be vetoed
  (publishes a cancellable RemoveChildEvent) - proceeding anyway could add
  the actor to the new room without ever having left the old one, and
  ended the encounter regardless of whether the move actually happened.
  Now mirrors MoveCommand's check-then-proceed order.

Also: Dockerfile was missing a COPY for the new SharpMud.Ruleset.Rpg.csproj
in the early project-file layer, so `docker build` failed restoring
Classic's csproj before src/ was copied wholesale - verified fixed with a
real `docker build`, not just by inspection. BasicRulesetOptions' class
summary is now a real XML doc comment (was a plain // comment, so it never
made it into generated IntelliSense/NuGet docs). The docsite's
ICombatOutcomeHandler sample now uses an explicit constructor instead of a
primary constructor, matching the coding standard consumers are meant to
copy. A couple of remaining stale docs mentions (ICombatant) cleaned up.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

…ee rollback)

CombatManager's encounter tracking assumed single-threaded access ("world
mutation happens on the single game-loop thread"), but that's only true for
tick-vs-tick ordering - AttackCommand/FleeCommand run inside whichever
session's independently-scheduled task happens to be executing a command
(TelnetTransportBackgroundService runs one task per connection), so
_encounters is genuinely accessed from multiple threads. The previous
round's IsDefenderEngaged-then-StartEncounter guard was a real TOCTOU race:
two players targeting the same NPC at nearly the same time could both
observe "not engaged" before either inserted, recreating the duplicate-XP
bug. Replaced StartEncounter with an atomic TryStartEncounter (check +
insert under one System.Threading.Lock critical section) and made every
other _encounters access go through the same lock. Added a real concurrent
test (32 attackers racing the same defender via Task.WhenAll/Task.Run,
asserting exactly one wins) alongside the sequential case, since the
sequential case alone wouldn't have caught the original race.

Also: FleeCommand checked Remove's cancelable result but not
destination.Add's - a vetoed Add (e.g. a future "room is full" behavior)
would leave the actor already removed from the encounter and their old
room, with success already announced, but never actually added anywhere.
Now rolls back into the original room and reports failure instead.

docs/combat.md's ICombatManager snippet/sequence updated for
IsDefenderEngaged, TryStartEncounter, the "someone else is already
fighting" message, and switched off the stale primary-constructor sketch.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

The per-tick loop fetched an encounter under _lock, then resolved a round
against that captured object outside the lock (necessarily, since holding
a lock across an await isn't possible). A concurrent FleeCommand (ending
this attacker's encounter) immediately followed by AttackCommand (starting
a new one against a different defender) could land in that window - the
tick would then resolve a round against the stale, already-replaced
encounter, and could wrongly EndEncounter the new one afterward based on
that stale round's outcome.

Added a second lock-guarded re-check immediately before resolving each
round: skip this tick for that id unless _encounters[thingId] is still
reference-equal to what was fetched. Narrows the actual race window to
nothing meaningful (no yield point between the check and the synchronous
resolve call that follows it).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>